Method for maintaining the look and feel of a user interface between uses

ABSTRACT

Methods and apparatus for maintaining the look and feel of a user interface between uses are disclosed. After validating the identity of a user, a user preferences file corresponding to the user ID may be accessed. A user interface may then have user-defined preferences restored in accordance with the user preferences file.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 10/703,823, filed Nov. 7, 2003, which is a continuation ofco-pending U.S. patent application Ser. No. 09/952,985, filed Sep. 14,2001, which is a continuation of U.S. patent application Ser. No.09/110,708, filed Jul. 7, 1998, now issued as U.S. Pat. No. 6,324,538,which is a continuation of U.S. patent application Ser. No. 08/572,543,filed Dec. 14, 1995, now issued as U.S. Pat. No. 5,778,367.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to on-line services, particularly toservices for the World Wide Web.

2. State of the Art

The Internet, and in particular the content-rich World Wide Web (“theWeb”), have experienced and continue to experience explosive growth. TheWeb is an Internet service that organizes information using hypermedia.Each document can contain embedded reference to images, audio, or otherdocuments. A user browses for information by following references. Webdocuments are specified in HyperText Markup Language (HTML), a computerlanguage used to specify the contents and format of a hypermediadocument (e.g., a homepage). HyperText Transfer Protocol (HTTP) is theprotocol used to access a Web document.

Part of the beauty of the Web is that it allows for the definition ofdevice-, system-, and application-independent electronic content. Thedetails of how to display or play back that content on a particularmachine within a particular software environment are left to individualweb browsers. The content itself, however, need only be specified once.In some sense, then, the Web offers the ultimate in cross-platformcapability.

Pre-existing collections of information, however, such as databases ofvarious kinds, can rarely be placed directly on the Web. Rather, gatewayprograms are used to provide access to a wide variety of information andservices that would otherwise be inaccessible to Web clients andservers. The Common Gateway Interface (CGI) specification has emerged asa standard way to extend the services and capabilities of a Web serverhaving a defined core functionality. CGI “scripts” are used for thispurpose. CGI provides an Application Program Interface, supported byCGI-capable Web servers, to which programmers can write to extend thefunctionality of the server. CGI scripts in large part produce fromnon-HTTP objects HTTP objects that a Web client can render, and alsoproduce from HTTP objects non-HTTP input to be passed on to anotherprogram or a separate server, e.g., a conventional database server. Moreinformation concerning the CGI specification may be accessed using thefollowing Universal Resource Locator (URL):http://hoohoo.ncsa.uiuc.edu/cgi/interfac.html

With the explosive growth of the Web, fueled in part by theextensibility provided by CGI scripts, the need for “finding aids” forthe Web, i.e., tools to allow one to find information concerning a topicof interest, has grown acute. Many hardcopy volumes are presentlyavailable that are represented to be “White Pages” or “Yellow Pages” forthe Web. Of course, hard copy information becomes rapidly out of date,and in the case of the Web, is out of date before it is even printed(let alone distributed), in the sense of failing to list manyinteresting resources newly made available on the Web.

The only effective solution is to have such finding aids be on-line,available on the Web itself. One such finding aid is a class of softwaretools called search engines. Search engines rely on automatedWeb-traversing programs called robots or spiders that follow link afterlink around the Web, cataloging documents and storing the informationfor transmission to a parent database, where the information is sifted,categorized, and stored. When a search engine is run, the databasecompiled through the efforts of the robots and spiders is searched usinga database management system. Using keywords or search terms provided bythe user, the database locates matches and possibly near-matches aswell.

An example of one such search engine is known as Yahoo, offered byYahoo! Corporation of Mountain View, Calif., and may be accessed at theURL http://www.yahoo.com. Persons having pages on the Web, rather thansimply waiting to have their Web page be found by a robot or spider, canalso have their Web page listed in the Yahoo database by providinginformation concerning the resource they wish to list and paying a fee.The result is an on-line-searchable directory of Web resources that isregularly updated.

While such services are indeed extremely useful, nevertheless, from thestandpoint of a person wishing to publicize their Web site, they aretypically attended by a number of drawbacks. In particular, the personwishing to publicize their Web site typically has very limited controlof the content of the resulting listing. Submissions, including textualdescription and suggested categories, are often subjected to editorialcontrol that may range from strict to arbitrary. As a result, a listingmay be placed under an entirely different category from the categoryintended by the person making the submission. Furthermore, the textualdescription may be heavily edited (in some instances almost beyondrecognition)—or even deleted—depending on the exaction of the editor.Because of this editorial process, posting of the listing is notimmediate. Furthermore, once the listing has been posted to thedatabase, if the person making the listing later wishes to change thelisting in some respect, the change must again pass through the samelaborious channel. Hence, the process of adding and updating listings isinconvenient and unsatisfactory.

Moreover, the nature of the listing is rather prosaic. The listing is intitle/brief-description format and does not include graphical elementsor otherwise appeal to the artistic sensibilities of the viewer. In thissense, the listing is comparable to the standard telephone book listing,which appears in plain text, nothing added, as compared, say, to aquarter-page advertisement with custom artwork and the like.

To use the foregoing service, one is required have a Web homepage. If auser has no Web presence but wishes to establish one, the foregoingservice is entirely unavailable. The typical user must first establish aWeb presence by paying a Web consultant to produce a homepage and thenpaying an Internet Service Provider to house that homepage on the Web.This undertaking can prove to be quite costly for an individual or asmall business.

What is needed, then, is an information service that overcomes theforegoing disadvantages.

SUMMARY OF THE INVENTION

The present invention, generally speaking, uses a computer network and adatabase to provide a hardware-independent, dynamic information systemin which the information content is entirely user-controlled. Requestsare received from individual users of the computer network toelectronically publish information, and input is accepted from theindividual users. Entries from the users containing the information tobe electronically published are automatically collected, classified andstored in the database in searchable and retrievable form. Entries aremade freely accessible on the computer network. In response to userrequests, the database is searched and entries are retrieved. Entriesare served to users in a hardware-independent page description language.The entries are password protected, allowing users to retrieve andupdate entries by supplying a correct password.

Preferably, the process is entirely automated with any necessary billingbeing performed by secure, on-line credit card processing. The usermaking a database entry has complete control of that entry both at thetime the entry is made at any time thereafter. The entry, when served toa client, is transformed on-the-fly to the page description language.Where the page description language is HTML and the computer network isthe World Wide Web, the entry may function as a “mini” homepage for theuser that made the entry. Provision is made for graphics and other kindsof content besides text, taking advantage of the content-rich nature ofthe Web.

Because the user controls both the content of an entry and the manner inwhich it is classified, the database functions as a directory to allowthe Web public to quickly and precisely find current and accurate dataabout the user, the user's products and services, etc., withoutrequiring the user to have a conventional Web homepage. The user's minihomepage can be included in many different categories, with the userhaving the flexibility to change the categories or the descriptivecontent of the page at any time. Preferably, hyperlink services are alsoprovided, by including within the page links to an E-mail address or toone or more other conventional homepages (or other mini homepages). TheE-mail address may be a private E-mail address established on the hostmachine, avoiding the need to obtain a conventional E-mail address. Aninexpensive way is therefore provided to set up a Web site with keyinformation that might otherwise be very costly to widely distribute,and to achieve an Internet presence with a minimum of effort andexpense.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be further understood from the followingdescription in conjunction with the appended drawing. In the drawing:

FIGS. 1A and 1B are simplified block diagrams of alternative embodimentsof the system of the present invention;

FIG. 2A through FIG. 2T are screen shots showing use of the system andmethod of the present invention;

FIG. 3 is a flowchart of the operational steps involved in the presentsystem and method;

FIG. 4 is a block diagram showing various ones of the HTML front-endingtools of FIG. 1 and their functional interrelationships; and

FIG. 5 is a simplified block diagram showing the manner in which whoisand traceroute services are made readily available through HTMLfront-ending and augmented with hyperlink services.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to FIG. 1A, there is shown a simplified block diagram of thesystem of the present invention. A server site 101 is connected to thecomputer network 103 such as the Web or a Wide Area Network (WAN) otherthan the Web. At the server site, server software runs on a suitableserver platform. In the case of the Web, for example, the server of FIG.1A might be a server available from the National Center forSupercomputing Applications (NCSA), or a secure server package of aknown, commercially-available type, running on a super-minicomputer suchas a SunServer machine available from Sun Microsystems of Menlo Park,Calif., or on any of a wide variety of suitable UNIX platforms. Alsorunning, either on the same machine or a network-accessible machine, isa database management system 107. Preferably, the database managementsystem 107 supports Standard Query Language, or SQL. One suitabledatabase management system is MiniSQL, which is also commerciallyavailable.

SQL databases, however, are not inherently “Web-friendly.” Accordingly,a variety of HTML front-ending tools 109 are provided which run asextensions to the server software, allowing computer network users toeach add entries to a database, search entries in the database, andupdate entries by that particular user, all using the Web (or aWeb-like) graphical user interface. The server software and the HTMLfront-ending tools communicate through the Common Gateway Interface 111.In accordance with another embodiment, shown in FIG. 1B, the HTMLfront-ending tools may be fully integrated with the server software. TheHTML front-ending tools and the database communicate through SQL (113).

When a network user visits the server site, the user is served a mainpage in a page description language such as HTML. The user interactswith the page, making selections or requests. These selections orrequests, although they may not appears as such to the user, are ineffect page requests, e.g., URLs that access a page directly or thatcall a CGI script to perform some sort of processing. The result of theselection or request may be a page eliciting a further selection orrequest, or may be contain the desired information itself.

In order to convey the manner in which the automated information serviceand directory is used, screen displays of the graphical user interfacewill now be described.

When a user first visits the site, he or she is presented with a mainpage as shown in FIG. 2A. Along the side of the page are icons that maybe clicked on to select different services. An icon 201 selects a“WebBook” service in which database entries may be searched, viewed andupdated. An icon 203 selects a “WebWho Whois” service, providing agraphical front end to the United States Whois database, with additionalhypertext link integration. An icon 205 selects the “WebWho Traceroute”service, providing a graphical front end to the Traceroute utility,again with additional hypertext link integration. An icon 207 in the topleft shows the current page's icon and is not linked.

When the icon 201 is selected, the user is presented with a page likethat shown in FIGS. 2B, 2C, and 2D. At the top of the page appears atable 209 presenting examples of valid entry types for Whois, i.e.,Domain Name, Machine Name, Registered Handle, Registered Name, IPAddress and IP Network. Next appears a text input field 211 to receivethe information to be looked up. Next appears an example of the resultsof a specific lookup. The user has input his or her request, and resultshave been received back and displayed in a results area 213. Asdescribed more fully below, links are embedded in the results such that,by clicking on an area 215 displaying ccoley@SRMC.COM, for example, anE-mail utility will be invoked showing a blank E-mail addressed toccoley@SRMC.COM. Similarly, domain names, IP addresses, etc. may beclicked on, with the result that Whois is queried once again withrespect to the selected information.

At the bottom of the page appears a Navigational Aid 217 used throughoutthe user interface where appropriate to allow the user to returndirectly to a particular entry point in the program flow without havingto follow numerous links as is typical of the prior art.

When the icon 203 is selected, the user is presented with a page for theTraceroute utility like that shown in FIGS. 2E and 2F. The variousfeatures of the page will be evident from the preceding description. Onefeature, however, bears particular mention. That is, just as clicking adomain name or the like in Whois produces a further query, bringing upadditional information, similarly, clicking on names or addresses inFIG. 2C also produces a further query, not of Traceroute but of Whois.For example, if one wanted to find additional information about themachine on line number of 1 of FIG. 2C, one could simply click on the IPaddress 205.138.192.1 displayed in the area 219. This action wouldproduce the same result as if the user had copied down the IP address,navigated to Whois and entered the IP address in the lookup field.

When the icon 205 is selected, the user is presented with a page likethat shown in FIG. 2G. The navigation aid previously described, althoughnot shown in FIG. 2G, may also be included if desired. The user is giventhe options of searching the database, adding a new entry, updating anexisting entry, changing the user's password, or logging in. Asdescribed below, login is typically not required to view a listing ofentries satisfying a particular search request, although login may berequired to view an actual entry itself and is required to update anentry.

When the Search option is selected, the user is presented with a pagelike that shown in FIG. 2H. Within WebBook, a different type ofnavigational aid 221 is included that allows the user to quickly moveabout within WebBook, between Search, Add and Update, or to go to themain page of FIG. 2A. The screen of FIG. 2H allows the user to selectbetween different searching methods, including searching by Categories(going through a categories list), by Example (querying each field ofthe entries), and by Keyword (specifying a keyword).

When Categories is selected, the user is presented with a page like thatshown in FIG. 2I. In the example shown, three root-level categories arepresented, BUSINESS, RECREATION, and WEBWHO95. The user selects one ofthese categories to show further subcategories, as seen in FIG. 23,which is displayed in response to the user selecting WEBWHO95. A singlesubcategory is shown—INDEX, having 9250 entries. The entries are listedby title within the lower part of the page. The user may select how manyentries are to be displayed at a time in order to quicken response time.Also, presorts are used in order to quickly display the results of acategory or keyword search.

When Example is selected, the user is presented with a page like thatshown in FIG. 2K. The user enters the information to be searched in anyfield or combination of fields to be searched.

To add a new entry to the database, the user is presented with a pagelike that shown in FIG. 2L. Each information item in the upper portionof the form is required, unless otherwise indicated. If a required itemis not provided, the program will redisplay the form and request theuser to complete all required items. Optional items include middle name,alternate phone number, fax number, URL#1, and URL#2.

The remainder of the form is used to enter up to twenty keywords and adescription of the user's entry, to be displayed with the entry.

Following entry of keywords and a description of the entry, the user isrequested to choose a category for the entry by presenting the user witha page like that shown in FIG. 2M. The user can navigate the categorytree until he or she has located the desired category and then selectthat category. If none of the categories is adequate, then the user maydefine his or her own category, by entering the name of the category anda short description of the category. The new category will then be addedto the category tree.

A sample mini homepage is shown in FIG. 2N and 2O. The mini homepage maybe located by searching the database and then selecting thecorresponding entry, or may be retrieved directly by URL. The URL of themini homepage itself should not be confused with URL#1 and URL#2 listedon the mini homepage. The latter refer to independent resources. The URLof the mini homepage itself is, for example, based on a uniquetransaction ID assigned to each entry and may be entered into a browserprogram to view the mini homepage directly without searching.

When Update is selected (FIG. 2G), the user, having entered the correcttransaction ID and password, is presented with a page like that shown inFIG. 2P. The corresponding mini homepage is displayed, and the user isrequested to update the mini homepage (the “post”). When the user hasedited the entry to his or her satisfaction, the user presses UPDATE.The user is then presented with a further page like that shown in FIGS.2Q and 2R, giving him or her the opportunity to review one final timethe comments and keywords. To change the comments or keywords, the userpresses BACK. The user can also change the category of the entry bypressing the Change category button. To accept and complete the update,the user presses a Done update button.

A page like that shown in FIG. 2S is then presented. The user isrequired to enter the identification number of the post. If theidentification number is entered correctly, the post is updated, and apage like that shown in FIG. 2T is presented to the user, confirming theupdate.

Referring now to FIG. 3, the operational steps involved in the presentsystem and method are represented. The system is accessed eitherdirectly by the user or by following a link to the server site, forexample the URL WebWho.com. The name WebWho.TM is a trademark of thepresent assignee.

The user is first presented with a page 301 (index.shtml) allowing theuser to select from different services, including whois and traceroute.As described previously, whois is an Internet service that looks upinformation about a user in a database. Traceroute is a program thatpermits a user to find the path a packet will take as it crosses theInternet to a specific destination. Whois and traceroute are knownservices. Previously, however, use of these services has typicallyrequired “root-user access” on a UNIX host. In accordance with oneaspect of the present invention, these services are HTML front-ended andmade available to all users, together with further hyperlink servicesthat greatly increase the utility of the underlying whois and tracerouteservices.

Referring to FIG. 5, whois and traceroute are made readily available toall network users through HTML front-ending using CGI scripts. Theactual whois code 501 and traceroute code 503 remains within the rootdirectory 500 on a UNIX host. Respective CGI scripts are provided,namely whois.cgi (505) and traceroute.cgi (507), that have root userprivileges and that provide HTML front-ending between the user and theirrespective services. For example, when a user selects the WebWho Whoisservice from the main page of FIG. 2A, the whois.cgi script 505 isinvoked to pass the user input to the root directory whois service 501and cause it to service the user's request. Output from the rootdirectory whois service 501 is passed back from the whois.cgi script 505in HTML format. The same description applies equally to thetraceroute.cgi script and the root directory traceroute service.

To further augment the whois and traceroute services, hyperlink servicesare provided. The root directory whois and traceroute services areprovided with a parsing routine 509 that parses the output of theseservices to identify E-mail addresses, domain names, IP names,etc.—character strings containing period separators and/or the character“@.” The parser then passes back this information to the CGI scripts inthe form of links, links to the whois.cgi script 505 in the case ofnames and links to an E-mail.cgi script 511 in the case of E-mailaddresses. The E-mail.cgi script 511 controls an E-mail utility 513 thatmay be located in the root directory or in a different directory.

Whois and traceroute, as implemented as part of the present invention,provide powerful new tools for serious Internet tools. Using whois, theuser may type in any address with a “.com”, “.edu” or “.net” extensionand find the physical address, phone number and the individual(s) thatthe address represents. This ability may be used as a powerful marketingtool to find a wealth of information about people on the Internet. Also,whois can be used to instantly check a domain name.

Traceroute may be used by System Administers to obtain information tomake their jobs much easier. Previously, System Administrators have notbeen allowed to use traceroute on a PC running any operating systemother than UNIX.

Whereas whois and traceroute are more technically oriented, “WebBook”allows non-technical users to take advantage of the capabilities of theWeb with a minimum of effort. WebBook allows a user to haveHTML-front-ended access to a database of mini homepages in order tosearch, add entries to, or update previous entries in the database.

Referring again to FIG. 3, if WebBook is chosen, a login routine 303 mayrequest the to enter identifying information of the type that wouldnormally be found on a business card, for example. Presently, althoughWeb sites are able to track the user's access point to the Web (forexample, a particular slip connection through an Internet ServiceProvider), this information often gives no indication who the userreally is. Such information is important in order to evaluate the extentto which a target audience is being reached.

The user may choose an option that allows the user to bypass the loginrequest. The request for information as to the identity of the usertherefore may or may not be complied with; moreover, the informationprovided may or may not be accurate. As an incentive to provide therequested information (and, it is hoped, the correct information), usersproviding the requested information may be given more complete access tothe database than users who do not provide the requested information.Users providing the requested information are assigned a user ID to beused during subsequent accesses and are requested to choose a password.The password may be required to access some system services. To furtherencourage voluntary login, users that have complied with the loginrequest and have been assigned a user ID may be afforded the ability tocustomize the user interface and maintain the resulting look and feelbetween uses. This customization is performed in a known manner bystoring on the host a user preferences file and accessing the file torestore user preferences when a valid user ID is provided.

For a period during the initial stages of the service, while thedatabase is still being built up, it may be desirable to allow all userscomplete access to the database regardless of whether or not they haveidentified themselves.

Following the login procedure, the user is provided with a page 305presenting the different ways that the user may interact with thedatabase. For example, a user may search the database, add a new entryto the database, or update a previous entry to the database by thatuser. Each of these options will be described in turn.

If the user chooses to search the database, the user is provided with apage 307 concerning different search options. A search may be performedon one or more of a number of different database fields, depending onthe organization of the database entries. For example, in a preferredembodiment, the database entries include the following defined fields:uid country fname email lname url mname keywords title comment identcategory phone 1 active phone 2 start.sub.-- date fax expire.sub.-- dateaddr info1 (Reserved) city info2 (Reserved) state info3 (Reserved)zipcode info4 (Reserved)

In one embodiment, searches may be performed by category, by keyword, byURL, or by example. To facilitate rapid retrieval of information,presorted listings may be stored for each category and keyword or forsome number of the most common categories and keywords. To search byexample, the user is provided with a form having the same organizationas the database entries. The user fills in information in the fields ofinterest. The search then returns information concerning entries havingmatching information in those fields. Entries are displayed in listfashion by title on a page 309.

The number of entries produced by a search may be very large. Therefore,instead of displaying a listing for all of the entries at once, theentries may be displayed ten at a time, for example. Alternatively, onlythe first 100 or 200 entries may be displayed.

While some sites may provide information and services free of charge,for example as a result of volunteerism or advertising subsidies, othersites may have a business model in which users are charged forinformation or services or both. For such a site, it becomes critical toprotect the information stored in the database. Therefore, unlike someexisting databases in which actual hypermedia links to Web homepages arestored in the listed items, in order to prevent effectual pirating ofthe database, links are embedded only in the full entry itself, not inthe entry listings. Otherwise a user could simply store a voluminouslisting or various different listings, with their accompanyinghypermedia links, and thereby capture in large part the entire benefitof the database. Instead, an item in a listing is intended only to givethe user enough information to gauge the user's further interest in anitem. If the user is interested in an item, the user may select thatitem, causing the full-page entry to be provided. The full page entryincludes links to any E-mail address or URL that the owner of the entrymay have provided, thereby providing a link to that person's ororganization's homepage (or to some other homepage).

If the user bypassed login, as determined in step 311, he or she willnormally be returned to the login procedure when attempting to select anentry to view it in its entirety. If the user has logged in, then theuser may select an entry and the corresponding full page 313 will beserved to the user.

The full page entry 313 need not be limited to text alone but may be acomplete hypermedia page, including possible graphics or othernon-textual content. In this manner, for person's or organizations nothaving any independent Web homepage, the entry can function as a“mini-homepage,” i.e., a single page hypermedia document. Furthermore,the mini-homepage may have its own URL, allowing it to be accesseddirectly without performing a search of the database. For example, a URLfor a mini homepage might be http://webwho.com/view?id=xxxx, where xxxxrepresents a transaction ID assigned to each entry in a manner describedbelow.

A link 315 is embedded in the mini-homepage to allow for the page to beupdated. Prior to describing the manner in which the mini-homepage isupdated, however, the manner of adding a new entry to the database willfirst be described.

In order to add an entry to the database, a user must login, duringwhich the user chooses a password, or must have logged in during aprevious visit to the site. When the user chooses to add a new entry tothe database, a unique transaction ID is created for that entry, to beused throughout the life of the entry. A unique transaction ID may becreated in any of many different ways. For example, the transaction IDmight be the date (e.g., 951215) and the entry number for that date(e.g., 00215). Alternatively, the transaction ID might be the time ofday (e.g., HHMMSS) and the process ID of the host machine process thatis servicing the user's request. In one embodiment, the transaction IDis a 14-digit hexadecimal number in which eight digits represent thenumber of seconds since an arbitrary date (e.g., Jan. 1, 1970), fourdigits represent the process ID running on the host machine, and twodigits represent a portion of the machine IP address (to distinguishbetween different host machines).

Once a transaction ID has been assigned, the user is then provided withan entry form 317 having fields corresponding to the various fields of adatabase entry as described previously. The user fills out the form andpresses a screen button when the entry is complete. The form may haveone or more checkboxes 319 to indicate the desire to include with theentry one or more non-textual elements, such as a graphic image, etc.Also, if desired, different templates may be provided governing theappearance of the finished page, with the user selecting a desiredtemplate.

Non-textual content may be obtained from the user in any of a number ofdifferent ways. For example, the user may transfer to the site a filecontaining the non-textual content using the File Transfer Protocol(FIP) with the same user ID and password as when the entry was added.

During the entry process, the user is prompted to enter keywords tofacilitate later searching of the database and location of the entry.Furthermore, the HTML front-end tools may assist in developing keywordsfor the entry. A pre-searchtsort tool, for example, might take the 2000top keywords found in the database within the keyword field and do atotal text search throughout the database for these keywords. If one ormore of these keywords appears in the description (“comment” field) ofan entry but not in the keyword list, these keywords are then added to akeyword extension field for up to some number of keywords, e.g. five.

If the server site is based on a pay-for-service model, the form willalso call for the user to enter a credit card number as the last pieceof information. Secure, on-line credit card processing will then beperformed to bill the user, either on a onetime basis, on a periodicbasis, or on an occasional basis as future services may require.Although various methods of processing credit card transaction on-linehave been proposed, with various degrees of attendant security, suchprocessing is preferably performed in accordance with a proprietarymethod developed by the assignee to provide the highest level ofsecurity possible.

After an entry has been made, it may be updated at any time by one ableto provide the transaction ID assigned to the entry and the userpassword, i.e., by the user or one acting on behalf of the user. Theupdate option may be entered directly, or the entry to be updated mayfirst be viewed as the result of a search and the update screen button315 then pressed. The user is then prompted to supply the correcttransaction ID and password (page 321), failing which the user will notbe allowed to update the entry.

If the transaction ID and password are correctly supplied, then theequivalent of a new entry form will be provided to the user will thecurrent information pertaining to the entry already filled in. The usermay then modify the entry. If a charge is made for updating the entry,preferably the credit card information from the earlier creation of theentry will have been stored in a highly secure fashion, avoiding theneed to reenter the information. Both security and convenience arethereby enhanced.

Nothing in the process of adding, searching and updating entriesrequires manual intervention. Rather, the entire process is automatedand may be made available continuously, 24 hours a day, 365 days a year.Like a publicly-accessible bulletin board, the content that is posted onthe database is entirely within the control of the user, both at thetime the entry is posted and all times thereafter.

Referring now to FIG. 4, various ones of the HTML front-ending tools ofFIG. 1 and their functional interrelationships will now be described.

When a user visits the site and the WebWho option is selected, a pageWebWho.html (401) is served to the user, offering the user variousoptions, including, for example, options to search the database, add anew entry, update an existing entry, change the user's password, or tolog in if the user has not previously done so. In an exemplaryembodiment, the routines illustrated in FIG. 4 are standard C routines,called from a single CGI script. In other embodiments, the routines maybe called by separate scripts, and may be written other languages suchas in a UNIX shell language, or in one of a number of emerging Internetcomputer languages such as Java.

The Options routine 403 reads in the user's choice and invokes one ofthe five following routines: Search (405), Add (407), Update (409),Changepw (411), and Login (413). Each of these options will be describedin turn.

If Search is chosen, the Search routine 405 initiates one of severalpossible search functions. In a preferred embodiment, these functionsinclude a categories search, an example search, and a keyword search.According to the search function chosen, the Search routine invokes oneof the following routines: Categories (415), Example (417), andKey.sub.—Search (419).

Categories are represented in computer memory in the form of a treestructure. A categories search starts from the root level, with theCategories routine 415 displaying all the categories available at thatlevel, and all the entries (or up to some number of entries) belongingto that level. The user can click on any category to go to the nextlevel, and can click on any entry to bring up the mini page of theentry.

If Example is chosen, the Example routine 417 displays a form for theuser to fill in any field he or she wants to search on. The Exampleroutine 417 reads in the information and displays all the entries thatmatch what has been specified.

If Keyword is chosen, the Key.sub.—ysearch routine 419 displays textboxes to read in up to a specified number of keywords (e.g., four) tosearch on. The Key.sub.—search routine 419 displays all the entries thatmatch the specified keywords.

When a user clicks on one of the entries returned by a search function,the mini page is displayed by a List.sub.—entries routine 421.List.sub.—entries displays the mini page for a particular entry and alsocontains an update button for the user to update that particular entry.

When a user specifies that he or she wants to edit the entry currentlybeing displayed, the Update routine 409 performs a check to see if thatpage belongs to the user currently logged in. If so, updating isinitiated by invoking an Update post routine 423. Otherwise, anUpdate.sub.—login routine 425 is called to allow the user to perform thecorrect login sequence. The Update.sub.—login routine 425 reads in auser ID and password and matches them against the database to determineif the user is the owner of the mini page currently being displayed.Updating is not allowed until the correct user ID and password areentered.

The Update-post routine 423 displays an entry form with values filled infrom the information stored in the database. It invokes a Do.sub.—updateroutine 427 to process the new values being entered. The Do.sub.—updateroutine reads in the new information, makes sure that all the requiredinformation is filled. If not, a routine Do.sub.—missing is invoked.When all of the required information has been supplied, aUpdate.sub.—key routine 429 reads in the keywords and comments from thedatabase entry, displays them, and asks the user to confirm. The usercan go ahead and update the database or can change the category theentry currently belongs to.

If the user chooses to change the category, a Change.sub.—cat routine431 displays all the categories at the root level. The user can click onone of the categories to go to the next level or can specify a newcategory on the current level. If the user chooses to go ahead andupdate the database, another form is displayed to read in theidentification number of the entry. A Get.sub.—ident routine 435 is theninvoked. If the user chooses to change the category, an Update.sub.—catroutine 433 handles navigation through the categories tree. It will keepdisplaying the categories on the current level until the user hasdecided on a category or has specified a new category.

The routine Get.sub.—ident 435 reads in the identification number andmatches it against the identification number stored in the database forthe current entry. If they match, the database is updated; otherwise,the program declines the update.

Entries may also be updated directly without searching, using the Updateroutine 409. If a user is currently logged in, the Update routine 409displays all the entries belonging to that user. Otherwise, theUpdate.sub.—login routine 425 performs a login and displays all theentries belonging to the newly logged-in user. The remaining updateroutines have already been described as a continuation of the searchoptions and will therefore not be further described.

When Add is selected, the Add routine 407 displays an empty form toallow the user to fill in all the information. The Add routine 407processes the information that has been entered, using theDo.sub.—missing routine to make sure that all the required informationis entered. The Do.sub.—missing routine displays the form again untilall the required information is entered.

After all the required information has been entered, a Get.sub.—inforoutine 437 displays another form to read in the keywords and comments.A Confirm.sub.—info routine 439 processes the keywords and comment beingentered and displays them again, asking the user to confirm. After theuser confirms the keywords and comments, a Pick.sub.—cat routine 441acquires the category using the same mechanism previously described inrelation to Update.sub.—cat. If the user is not logged, in he or she islogged in, and a new user ID is determined. A form is then displayed toread in the user's password. A Get.sub.—pw routine 443 reads in thepassword and displays a form to read in credit card information. AGet.sub.—cc routine 445 verifies the credit card information. If thetransaction is authorized, it adds the new entry into the database;otherwise, it rejects the entry.

The remaining routines are administrative in nature. The user may wishto change his or her password. If the user is not currently logged in, alogin is performed by calling a Changepw.sub.—login routine 447.Changepw.sub.—login reads in the user ID and password and matches themagainst the values in the database. A form is then displayed to read inthe new password. The Changepw routine 411 actually updates the databasewith the new password.

The Login routine 413 reads in the user ID and password and checks themagainst the database. If the user ID and password are correct, operationbegins at the main page with the user logged in as the new user.

It will be appreciated by those of ordinary skill in the art that theinvention can be embodied in other specific forms without departing fromthe spirit or essential character thereof. The foregoing description istherefore considered in all respects to be illustrative and notrestrictive. The scope of the invention is indicated by the appendedclaims, and all changes which come within the meaning and range ofequivalents thereof are intended to be embraced therein.

1. A method for maintaining the look and feel of a user interfacebetween uses comprising: receiving a request from a user to access a webpage; querying the user for a user ID; responsive to receiving a validuser ID from the user, accessing a user preferences file correspondingto the user ID; and restoring user-defined preferences of a userinterface in accordance with the user preferences file.
 2. The method ofclaim 1, further comprising the act of presenting the user with a pagefor adding entries to an on-line database.
 3. The method of claim 2,further comprising the act of allowing the user to index said entries byone of a category, keyword, or URL.
 4. The method of claim 3, furthercomprising the act of assigning a Transaction ID corresponding to eachentry.
 5. The method of claim 4, further comprising the act of allowinga user to add at least one link to either of an email address or a URLlink corresponding to an entry.
 6. The method of claim 4, furthercomprising the act of allowing a user to add a graphical image to anentry.
 7. An apparatus for maintaining the look and feel of a userinterface between uses comprising: means for receiving a request from auser to access a web page; means for querying the user for a user ID;means for accessing a user preferences file corresponding to the user IDresponsive to receiving a valid user ID from the user; and means forrestoring user-defined preferences of a user interface in accordancewith the user preferences file.
 8. The apparatus of claim 7, furthercomprising means for presenting the user with a page for adding entriesto an on-line database.
 9. The apparatus of claim 8, further comprisingmeans for allowing the user to index said entries by one of a category,keyword, or URL.
 10. The apparatus of claim 9, further comprising meansfor assigning a Transaction ID corresponding to each entry.
 11. Theapparatus of claim 10, further comprising means for allowing a user toadd at least one link to either of an email address or a URL linkcorresponding to an entry.
 12. The apparatus of claim 10, furthercomprising means for allowing a user to add a graphical image to anentry.
 13. A web server configured for maintaining the look and feel ofa Hyper Text Markup Language (HTML) front-ended publicly accessibledatabase comprising: a server site connected to a public network; webserver software operatively disposed within said server site; HTMLfront-ending tools operatively coupled to the server site and configuredto communicate through a publicly accessible user interface; databasemanagement software operatively coupled to the HTML front-ending tools;and said HTML front-ending tools being configured to: receive a requestfrom a user to access a web page; query the user for a user ID; access auser preferences file corresponding to the user ID; validate saidreceived user ID; and restore user-defined preferences of a userinterface in accordance with the user preferences file.
 14. The webserver of claim 13, wherein an entry may be created by said user thatmay be retrieved and displayed over the publicly accessible network bysearching said site using a keyword associated with a user-definedcategory.
 15. The web server of claim 14, wherein said server isconfigured to allow a user to update their entry over the publicnetwork.
 16. The web server of claim 15, wherein said server isconfigured to allow a user to add an image to their entry.
 17. The webserver of claim 16, wherein said server is configured to create aTransaction ID for associating personal information of a user with adatabase entry and associated contents.
 18. The web server of claim 17,wherein said server is configured to allow the user to add a new entry.19. The web server of claim 18, wherein said new entry is associatedwith said user through said Transaction ID.
 20. The web server of claim13 wherein said HTML front-ending tools are written in C and configuredas a CGI script.
 21. The web server of claim 13 wherein said HTMLfront-ending tools are written in Java and configured as a Java script.22. The web server of claim 13 wherein said HTML front-ending tools arewritten in a Unix shell language.
 23. The web server of claim 15 whereinsaid HTML front-ending tools are written in C and configured as a CGIscript.
 24. The web server of claim 15 wherein said HTML front-endingtools are written in Java and configured as a Java script.
 25. The webserver of claim 15 wherein said HTML front-ending tools are written in aUnix shell language.